Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Klib support #183

Merged
merged 54 commits into from
Mar 18, 2024
Merged

Klib support #183

merged 54 commits into from
Mar 18, 2024

Conversation

fzhinkin
Copy link
Collaborator

@fzhinkin fzhinkin commented Jan 31, 2024

This PR introduces KLib ABI validation support in the BCV plugin.

The brief overview of the design and decisions made is in the corresponding design doc: https://github.com/Kotlin/binary-compatibility-validator/blob/50ebf8b00492d754732e47453b4d8d0351f33baa/docs/design/KLibSupport.md

Providing a programmatic API similar to the kotlinx.validation.api API for working with JVM ABI is planned, but this PR does not include it.

Besides the design doc mentioned above, the main entry points for reviewing are

where all the Gradle tasks are configured and where the current dump merging logic reside.

@fzhinkin fzhinkin linked an issue Jan 31, 2024 that may be closed by this pull request
@fzhinkin fzhinkin marked this pull request as ready for review February 5, 2024 11:10
@fzhinkin fzhinkin added the enhancement New feature or request label Feb 5, 2024
@fzhinkin fzhinkin requested a review from shanshin February 5, 2024 11:17
Input klib dump files were not tracked as merger dependencies,
so the merged dump was not updated when apiDump was re-executed
after sources update
Copy link
Member

@sandwwraith sandwwraith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't look at the implementation itself, but I decided to post comments now, because they were pending for too long

/**
* Specify which version of signature KLib ABI dump should contain.
*/
public var signatureVersion: Int = 2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this setting need to be exposed to end users? Can't we infer it from klib file itself?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can, that's for sure. But when the default/latest version will change, old dumps will be invalid. So there should be a way to specify a particular version.
But here we should probably use some latest-version-available alias instead of the concrete version 2.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get it. If the klib version changes, it means .klib.api file format (not actual signatures) would also change? That looks undesirable. Probably we should have some intermediate parser layer that would provide stable output.

Also, if klib version changes to 3, but user has signatureVersion = 2 it means that we parse klib v3 but output should look like 2. Which brings us again to some middle-layer transformation.

Copy link
Collaborator Author

@fzhinkin fzhinkin Feb 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A klib may have multiple signature versions. For example, each declaration may have both v1 and v2 signatures.
The signature is a part of a dump we're producing, so when it changes, the dump also change.

Probably we should have some intermediate parser layer that would provide stable output.

Not sure how we can do that. Signatures are part of a declaration as a linker looks up for symbols by their signatures. And there may be no direct mapping between different signature versions and a declaration they belong to.

Also, if klib version changes to 3, but user has signatureVersion = 2 it means that we parse klib v3 but output should look like 2. Which brings us again to some middle-layer transformation.

We parse the same klib, but instead of dumping v2 signature, will dump v3 signature.

A klib's dump with v1 signature:
https://github.com/Kotlin/binary-compatibility-validator/blob/f5fdacf4d2e9548144f522aa2924742ac4e473f5/src/functionalTest/resources/examples/classes/TopLevelDeclarations.klib.v1.dump
The dump of the same klib using v2 signature:
https://github.com/Kotlin/binary-compatibility-validator/blob/f5fdacf4d2e9548144f522aa2924742ac4e473f5/src/functionalTest/resources/examples/classes/TopLevelDeclarations.klib.dump

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, v3 actually can't link with v2 because they're incompatible? But newer klibs will have both 3 and 2 sets for backwards compatibility?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, v3 actually can't link with v2 because they're incompatible?

Yes, the linker won't be able to lookup symbols.

But newer klibs will have both 3 and 2 sets for backwards compatibility?

There's no v3 on the horizon right now, so it's hard to tell.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs here should guide user when to rely on the default value and when to set it to a fixed value.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Set the null as a default, mentioned that a user should not care about the option by default.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilya-g @sandwwraith are you ok with how the version is currently declared and documented?

* By default, ABI dumped only for supported files will be validated. This option makes validation behavior
* stricter and treats having unsupported targets as an error.
*/
public var strictValidation: Boolean = false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't these values be of type Property<Boolean> to support some Gradle configuration feature? Was it configuration cache or something else, @shanshin ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Configuration cache seems to work fine with primitive values. But if there's a case where Properties are better, I can change it (note that a parent class, ApiValidationExtension don't use Property too).

Co-authored-by: Leonid Startsev <[email protected]>
@fzhinkin
Copy link
Collaborator Author

fzhinkin commented Mar 7, 2024

What's new:

  • added public API for managing merged dumps
  • Gradle tasks were rewritten to use that API
  • supported dumps generated for klibs with multiple native targets inside (hello, stdlib)
  • changes KlibTarget serialized form
  • get rid of some options affecting plugin and the API
  • fixed dump filter to use java class name format
  • added tests for the API
  • updated the design doc

- fixed naming
- simplified some code constructions
- swapped the order of KlibTarget fields
- updated merged dump's header
- removed unsupported targets from target hierarchy
@fzhinkin fzhinkin requested a review from ilya-g March 12, 2024 10:58
Copy link
Member

@ilya-g ilya-g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot to submit the last portion of comments

@fzhinkin fzhinkin merged commit ad1bea6 into develop Mar 18, 2024
3 checks passed
shanshin pushed a commit to JetBrains/kotlin that referenced this pull request Oct 28, 2024
Added experimental Klib ABI dump validation support.
Validation could be performed using the Gradle plugin
which provides almost the same validation and dump workflow
as for JVM ABI validation.
Also, a public API was added to allow users who don't want or
can't use the plugin to implement their own workflows.

---------

Co-authored-by: Leonid Startsev <[email protected]>
Co-authored-by: ilya-g <[email protected]>
Pull request Kotlin/binary-compatibility-validator#183
shanshin pushed a commit to JetBrains/kotlin that referenced this pull request Dec 3, 2024
Added experimental Klib ABI dump validation support.
Validation could be performed using the Gradle plugin
which provides almost the same validation and dump workflow
as for JVM ABI validation.
Also, a public API was added to allow users who don't want or
can't use the plugin to implement their own workflows.

---------

Co-authored-by: Leonid Startsev <[email protected]>
Co-authored-by: ilya-g <[email protected]>
Pull request Kotlin/binary-compatibility-validator#183
shanshin pushed a commit to JetBrains/kotlin that referenced this pull request Dec 13, 2024
Added experimental Klib ABI dump validation support.
Validation could be performed using the Gradle plugin
which provides almost the same validation and dump workflow
as for JVM ABI validation.
Also, a public API was added to allow users who don't want or
can't use the plugin to implement their own workflows.

---------

Co-authored-by: Leonid Startsev <[email protected]>
Co-authored-by: ilya-g <[email protected]>
Pull request Kotlin/binary-compatibility-validator#183
shanshin pushed a commit to JetBrains/kotlin that referenced this pull request Dec 23, 2024
Added experimental Klib ABI dump validation support.
Validation could be performed using the Gradle plugin
which provides almost the same validation and dump workflow
as for JVM ABI validation.
Also, a public API was added to allow users who don't want or
can't use the plugin to implement their own workflows.

---------

Co-authored-by: Leonid Startsev <[email protected]>
Co-authored-by: ilya-g <[email protected]>
Pull request Kotlin/binary-compatibility-validator#183

Moved from Kotlin/binary-compatibility-validator@ad1bea6
KotlinBuild pushed a commit to JetBrains/kotlin that referenced this pull request Jan 3, 2025
Added experimental Klib ABI dump validation support.
Validation could be performed using the Gradle plugin
which provides almost the same validation and dump workflow
as for JVM ABI validation.
Also, a public API was added to allow users who don't want or
can't use the plugin to implement their own workflows.

---------

Co-authored-by: Leonid Startsev <[email protected]>
Co-authored-by: ilya-g <[email protected]>
Pull request Kotlin/binary-compatibility-validator#183

Moved from Kotlin/binary-compatibility-validator@ad1bea6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Validate KLIB ABI compatibility on Multiplatform
4 participants